1. Field of the Invention
The present invention relates to automation and validation techniques for designing electronic circuits. In particular, the present invention relates to automation and validation techniques for designing electronic circuits that are particularly applicable to system-on-a-chip type electronic circuits.
2. Description of the Related Art
It is conventional to use field programmable gate array (FPGA) devices from vendors such as Xilinx and Altera to prototype application specific integrated circuits implemented as masked gate arrays or standard cells. However the limitation of pins is a barrier to debugging an incorrect design. Individual FPGAs may have their observability enhanced by embedding Logic Analyzer intellectual property but at a cost of routing and logic resources which negatively impacts the amount of user logic that can easily be placed and routed automatically. A single FPGA being debugged may be attached to a host computer for control and display. It is awkward for two FPGAs to work together and be attached to separate host computers.
It is known that Field Programmable Gate Arrays (FPGA) are used for prototyping large electronic circuits and that tools and methodologies exist for debugging the signals on any one FPGA. These tools require substantial routing and logic resources of each FPGA which are not available for the prototype.
A problem exists where debugging a complex electronic circuit requires a plurality of FPGA. While it is possible to emulate each FPGA of a prototype which requires multiple FPGAs, it is extremely difficult to understand problems which cross the boundaries of one FPGA to another FPGA. It is known that the single chip FPGA debugging solution does not scale.
A first generation system controls an FPGA compiler to deliver signals which are to be observed, to the external pins. But input and output pins are frequently the bounding resource in FPGAs and functional blocks may not fit at all into an FPGA with reduced pins.
A second generation system embeds a simple internal logic analyzer to trigger off a simple logic equation and deliver on a small sequence of events. Multiple instances of this internal logic analyzer were required to be useful and functionality was thinner than desired.
A third generation system combines a plurality of FPGAs but only allows one of the FPGAs to be probed. This could only debug problems that luckily originated in one part of the design. It was unable to deal with problems that spanned the FPGA partitioning.
A conventional FPGA debugging tool is restricted to the signals within a single FPGA and consumes resources which reduce the amount of user logic that may be implemented within the single FPGA. This makes place and route of the user logic more difficult because both pin, logic elements, and channels are consumed by the debugging circuit.
Here are the conventional steps in the design flow:                1. Conventional: Set up user design        1a. Perform initial design entry        1b. Perform synthesis and place-and-route        1c. Program the single device and test        2. Conventional: Set up conventional embedded logic analyzer        2a. Create file of signals desired for observability        2b. Select signals for analysis        2c. Setup signals, triggers, conditional triggers, hierarchical triggers        3. Conventional: Capturing, Displaying, and Analyzing Sample Signal Values        3a. Re-program the single device and test        3b. Displaying the sampled signal values on attached host computer        3c. Analyzing data to identify problems in the user design.        
Thus it can be appreciated that what is needed is a way to debug a “system on a chip” which occupies, in its prototype form, a plurality of FPGAs. In particular, the problem being solved is to trigger logic value capture as a result of a combination of signal sequences internally used among a plurality of FPGAs.